Summary (AI generated)

The failing test AlgorithmTest::testEcdsaP256RoundTrip is a random flake. The chain:

1. The test helper ecKeyPair() generates a fresh EC key each run and builds a JWK from openssl_pkey_get_details()['ec']['x']/['y'].
2. PHP returns those coordinates via BN_bn2bin(), which strips leading zero bytes — so ~1 in 256 coordinates comes back 31 bytes instead of 32.
3. firebase/php-jwt's JWK::parseKey() concatenates the decoded coordinates directly into the uncompressed EC point (0x04 || x || y), which OpenSSL requires to be exactly 65 bytes for P-256. A short coordinate produces a malformed point → the warning openssl_verify(): Supplied key param cannot be coerced into a public key → verify returns false.

RFC 7518 §6.2.1.2 requires JWK coordinates zero-padded to the full field size. Production code already does this correctly (OCMSignatoryManager::buildEcdsaP256JwkArray) — only the test helper forgot.

Why "only on PHP 8.3"?

It actually isn't version-specific — that run was just unlucky. I checked php-src: both PHP 8.3 and 8.5 use the same unpadded BN_bn2bin in openssl_pkey_get_details(). I then ran a 2000-iteration repro in both php:8.3-cli and php:8.5-rc-cli containers: both produced short coordinates at the expected ~0.5–0.9% rate, and every short coordinate failed verification. Each CI job generates its own random keys, so with roughly a 1–3% failure chance per job, the 8.3 job happened to draw a bad key while the 8.5 job didn't. A re-run could just as well have failed on 8.5.

The fix

In tests/lib/Security/Signature/Rfc9421/AlgorithmTest.php, ecKeyPair() now pads both coordinates via a new zeroPadCoordinates() helper (as you suggested) — 32 bytes for P-256, 48 for P-384. Verified: 100 consecutive runs of the ECDSA tests in the dev container, all green, and the repro loop shows zero failures with padding on both PHP versions.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI